Diameter messages use a per user framework and exist in the format of request-answer messages. Diameter answer messages travel back to the request source via the same path through which the request message was routed using hop-by-hop transport. When one Diameter node needs information from another Diameter node, the first Diameter node sends a request identifying itself and its realm or domain, as well as identifying the realm or domain of the Diameter node from which the first Diameter node needs information. The Diameter answer message sent back from the Diameter node that receives the request will include information identifying the receiving Diameter node and its realm or domain.
One particular use for Diameter protocol is for requesting and receiving a subscriber policy for controlling network access among other things. For example, Diameter messages can be used to request a policy of a subscriber from a node referred to as a policy charging and rules function (PCRF) and to communicate with another node referred to as a policy charging enforcement function (PCEF), which enforces the policy.
In some instances, a policy may change based on particular conditions being met. For example, network or area congestion may trigger the PCEF to request a new policy for a subscriber. If Diameter protocol or another protocol that works per user is used, each subscriber may report congestion to the PCEF, the PCEF may request a policy from the PCRF, and a new policy may be provided from the PCRF to the PCEF for the subscriber. Accordingly, if a condition affects multiple subscribers, a network can experience problems attempting to trigger new policies, such as network overload from policy-related messaging.
Accordingly, in light of these shortcomings, there exists a need for methods, systems, and computer readable media for condition-triggered policies.